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ABSTRACT 

This  paper  describes  a  mechanism  for  improving  rendering 
rates  dynamically  during  runtime  in  an  interactive  three- 
dimensional  graphics  application.  Well-known  techniques 
such  as  transforming  hierarchical  geometry  into  a  flat  list 
and  removing  redundant  graphics  primitives  are  often 
performed  off-line  on  static  databases,  or  continuously 
every  rendering  frame.  In  addition,  these  optimizations  are 
usually  performed  over  the  whole  database.  We  observe  that 
much  of  the  database  remains  static  for  a  fixed  period  of 
time,  while  other  portions  are  modified  continuously  (e.g. 
the  camera  position),  or  are  repeatedly  modified  during 
some  finite  interval  (e.g  during  user  interaction).  We  have 
implemented  a  runtime  optimization  mechanism  which  is 
sensitive  to  repeated,  local  database  changes.  This 
mechanism  employs  timing  strategies  which  optimize  only 
when  the  cost  of  optimization  will  be  amortized  over  a 
sufficient  number  of  Irames.  Using  this  optimization 
scheme,  we  observe  a  rendering  speedup  of  roughly  2.5  in 
existing  applications.  Wc  discuss  our  initial  implementation 
of  this  mechanism,  the  improved  timing  measurements,  the 
issues  and  assumptions  we  made,  and  future  improvements. 
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INTRODUCTION 

In  1976  Clarke  suggested  that  a  hierarchical  data  structure 
would  have  several  characteristics  which  are  useful  for 
manipulating  and  rendering  graphics  objects  [4],  One  pow¬ 
erful  advantage  of  a  tree  structure  for  the  application  pro¬ 
grammer  is  that  matrices  at  each  node  in  the  tree  can 
represent  individual  coordinate  systems.  When  the  pro¬ 
grammer  manipulates  a  graphics  object,  its  children  will 
inherit  the  changes  implicitly  [  1 3] . 

However,  for  the  rendering  engine,  a  hierarchical  data  struc¬ 
ture  is  not  optimal.  To  keep  the  highly  pipelined  architecture 
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of  modem  graphics  hardware  from  stalling,  we  would  prefer 
to  make  few,  if  any  calculations  while  traversing  the  graph¬ 
ics  database.  To  that  end,  a  flat  list  of  graphics  primitives  is 
preferable,  because  it  requires  no  combination  of  transfor¬ 
mations  (e.g.  matrix  multiplications).  Flat  lists  also  offer  the 
opportunity  to  perform  compiler-like  peephole  optimiza¬ 
tions  (e.g.  removing  redundancies),  and  is  efficient  for  pipe¬ 
lining  graphics. 

Existing  Solutions 

The  use  of  optimization  techniques  to  improve  rendering 
speeds  is  well-established,  in  both  research  (e.g.  the  Berke¬ 
ley  and  UNC  Walkthrough  projects  [7][1][2])  and  commer¬ 
cial  systems  (e.g.  SGI  Performer  [11]).  These  two  systems 
exemplify  both  ends  on  the  spectrum  of  when  to  optimize. 
The  Berkeley  Walkthrough  assumes  that  the  database  is 
static,  and  can  perform  aggressive  off-line  optimization  to 
restructure  the  database  for  improved  runtime  performance. 
Performer,  on  the  other  hand,  supports  very  dynamic  envi¬ 
ronments  and  cannot  make  assumptions  about  the  static 
nature  of  the  database.  Performer  employs  global  database 
optimization  for  every  frame.  Since  optimization  takes  time, 
Performer  users  prefer  to  execute  these  mechanisms  on  an 
auxiliary  CPU  to  minimize  impact  on  the  rendering  CPU. 
Both  techniques  apply  optimization  globally  over  the  data¬ 
base. 

In  this  paper,  we  present  optimizations  that  occurs  after 
higher-level  techniques  such  as  culling  objects  which  are 
not  in  view,  or  using  multiple  representations  of  objects 
stored  at  various  levels  of  detail  [12], 

Our  Approach 

We  have  observed  that  in  many  applications  some  portions 
of  the  database  remain  unchanged  during  the  entire  run,  and 
other  portions  change  repeatedly,  but  during  brief  intervals 
(e.g.  when  the  user  is  directly  manipulating  the  object),  and 
still  other  portions  change  continuously  (e.g.  the  camera 
location). 

Since  we  have  constructed  a  rendering  system  which  is 
application  independent  [8],  we,  like  Performer,  cannot 
make  assumptions  that  a  given  portion  of  the  database  will 
remain  static.  We  must  analyze  the  database  during  runtime. 
Instead  of  attempting  to  transform  the  entire  database  dur¬ 
ing  each  frame,  our  mechanism  records  the  frequency  with 
which  portions  of  the  database  change,  and  uses  this  infor- 
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mation  to  predict  how  frequently  the  object  will  be 
changed  in  the  near  future.  The  mechanism  determines 
or  predicts  the  cost  ot  performing  an  optimization  and 
uses  a  simple  utility  function  to  determine  the  value  of 
optimizing  those  portions  of  the  database.  The  algorithm 
collects  data  about  the  average  frequency  for  which 
each  object  gets  altered  If  the  object  does  not  get  altered 
frequently,  then  the  cost  to  optimize  the  object  may  be 
worth  the  savings  recouped  over  later  frames.  However, 
if  the  object  is  constantly  changing,  then  there  is  less 
incentive  to  perform  the  optimization,  as  the  benefits 
will  be  fleeting.  Our  approach  is  a  hybrid,  as  shown  in 
Figure  1 : 
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Figure  1:  When  to  optimize 


OUR  TECHNIQUE 

Our  technique  involves  several  optimization  phases  and 
a  separate  mechanism  for  analyzing  the  benefit  of  per¬ 
forming  the  optimizations.  The  phases  are: 

•  streamlining  each  individual  node  in  the  tree  by  cre¬ 
ating  an  array  of  graphics  calls  without  any  interven¬ 
ing  computations.  This  is  done  for  each  node  in  the 
tree,  so  that  if  the  node  is  altered,  only  that  particular 
node’s  streamlined  array  needs  to  be  re-constructed 

streamlined  list  of  grapnics  — -x 

a  —  A^r 


•  peephole  optimization  to  the  streamlined  list, 
removing  redundancies 


- rry-r^ 


•  flattening  the  hierarchical  tree  structure  —  coalescing 
nodes  so  that  each  subtree  node  has  a  single  cache 
list  representing  all  of  its  children  at  one  trans¬ 
formed  level.  We  call  this  list  the  streamlined  array. 


The  Tree  Structure 

We  implemented  our  optimization  mechanism  as  part  of 
the  Alice  graphics  svstem  1 10].  Alice  supports  a  variety 
of  applications  ranging  from  immersed  virtual  environ¬ 
ments.  to  rapid  exploration  of  three-dimensional  inter¬ 
faces.  to  a  teaching  tool  for  graphics  classes.  The 
rendering  subsystem  |8]  is  based  on  a  hierarchical  data 
structure.  All  graphical  objects  in  the  rendering  sub-sys¬ 
tem  are  represented  as  nodes  in  the  tree.  Nodes  contain 
transformation  matrices  and  may  also  contain  geometry 
consisting  of  polygons,  polylines  or  polypoints. 

When  rendering  from  this  data  structure,  there  are  two 
basic  forms  of  inefficiency: 

1)  matrix  multiplications  to  combine  the  implicitly 
chained  transformations  (in  order  to  render  a  leaf  node, 
we  must  first  apply  all  the  transformations  from  the  root 
node  to  that  leaf). 

2)  redundant  calls  to  set  state  in  the  graphics  pipeline: 
for  example,  in  most  objects,  a  large  number  of  poly¬ 
gons  are  the  same  color.  Repeatedly  calling  the  graphics 
setColor()  subroutine  (the  OpenGL 
glColor3f  ( )  call)  [9]  disrupts  the  pipeline.  In  addi¬ 
tion,  even  using  a  local  if  statement  in  the  inner  render¬ 
ing  loop  also  disrupts  the  hardware  pipeline  [5], 
degrading  rendering  performance.  This  is  partially 
because  the  if  statement  to  compare  with,  for  exam¬ 
ple,  the  current  nonnal  vector,  needs  to  compare  three 
floating  point  values  The  most  efficient  mechanism  is  to 
produce  the  list  of  giaphics  calls  which  will  be  stream¬ 
lined  into  the  graphics  pipeline,  and  to  remove  the 
redundant  calls.  This  is  exactly  what  Performer  does  on 
an  extra  CPU  for  each  Irame. 


•  peephole  optimization  of  the  flattened  list  for  the 
entire  subtree 


O - 1  1  1  |  - ►  Q 


Since  invoking  these  optimization  mechanisms  requires 
time,  we  need  a  guideline  to  determine  if  it  is  worth  per¬ 
forming  these  operations.  The  algorithm  must  evaluate 
the  time  needed  to  perform  the  optimizations,  how  long 
the  object  has  remained  unaltered  and  how  much  of  a 
predicted  improvement  will  be  achieved. 

Optimization  Phases 

Converting  Each  Node  into  a  Rendering  List 

Each  node  in  the  tree  may  be  thought  of  as  a  container 
holding  a  set  of  properties  describing  the  object  or  sub¬ 
object  at  that  level.  For  example,  in  a  hierarchical  model 
of  a  bunny,  the  bunny’s  foot  may  be  a  child  of  the 
bunny’s  leg.  As  a  node,  the  foot  contains  geometry, 
color  information  and  inherits  the  transformation  matrix 
from  its  parent  (the  leg).  When  traversing  the  foot’s 
node,  the  rendering  engine  may  have  to  perform  several 
conditional  statements  to  determine  how  to  draw  the 
foot.  The  color  may  be  inherited  from  the  parent  (the 
leg),  set  for  all  of  the  polygons,  be  specified  for  each 
individual  polygon,  or  specified  for  each  individual  ver¬ 
tex  of  each  polygon.  Evaluating  these  conditional  state - 
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merits  every  frame  disrupts  the  pipeline.  If  the  graphics 
calls  are  the  same  Irom  frame  to  frame,  these  calls  can 
be  cached  into  an  array.  Then  the  rendering  engine  can 
iterate  through  the  array  rather  than  making  repeated 
conditional  evaluations.  While  it  is  surprising  that  seem¬ 
ingly  minor  conditional  tests  have  a  strong  impact  on 
rendering  performance,  this  is  due  to  the  highly  pipe¬ 
lined  nature  of  high-end  graphics  hardware.  To  quote 
the  authors  of  SGI  Performer: 

“ The  data  structures  used  to  represent  geometry  and  the 
code  which  transfei  s  that  data  to  the  graphics  hardware 
very  often  make  01  /weak  an  immediate-mode  graphics 
application."  [II] 

Peephole  Optimization 

When  rendering  an  object,  there  are  many  polygons 
which  are  the  same  color  Instead  of  resetting  the  color 
for  every  vertex  or  tor  every  polygon,  the  color  call  can 
be  factored  out  and  made  only  once. 

This  redundancy  factoring  can  occur  for  many  of  the 
properties  which  characterize  the  object  (e.g.  the  color, 
the  vertex  normal  \  colors,  and  the  textures).  For  the  ini¬ 
tial  implementation,  our  optimization  removes  redun¬ 
dant  color  and  normal  information  This  operation  is 
performed  during  the  construction  of  the  streamlined 
array. 

Early  peephole  compilers  used  a  similar  method  to  track 
the  source  of  a  register's  value  and  remove  redundant 
load  commands  [Aj  More  sophisticated  peephole  opti¬ 
mizers  perform  increasingly  complex  pattern  matching 
and  even  rearrange  code  in  an  attempt  to  minimize  the 
number  of  instructions  and  register  manipulations:  we 
hope  to  use  a  numbet  of  these  techniques  to  further  opti¬ 
mize  rendering. 

Flattening  the  Tree 

Since  the  optimization  mechanism  is  traversing  the  hier¬ 
archical  structure  anil  creating  cache  arrays  for  each 
node,  the  cost  to  accumulate  the  transformation  matrices 
is  trivial.  This  allows  the  optimization  mechanism  to 
effectively  flatten  subtrees  into  a  single  node  with  a 
longer  cache  array. 


Note  that  the  original  hierarchy  is  not  discarded,  since 
alterations  to  the  nodes  in  the  tree  require  that  the  cache 
be  invalidated  and  the  original  hierarchy  be  available. 

Flattening  the  hierarchs  into  a  rendering  list  is  an 
explicit  junction  call  in  Performer,  and  therefore  makes 
it  the  responsibility  ol  the  application  programmer  to 


perform  this  operation.  Our  optimization  mechanism 
engages  automatically  when  optimization  is  cost-effec¬ 
tive. 

Analysis  Mechanism 

The  important  distinction  of  our  mechanism  is  how  it 
determines  when  optimization  should  be  done,  and  to 
which  portions  of  the  database.  Performer  does  optimi¬ 
zation  globally  to  the  entire  hierarchy  every  frame.  Our 
approach  is  to  perform  a  utility  measurement,  compar¬ 
ing  the  cost/benefit  of  flattening  subtrees  and  factoring 
out  redundant  calls.  We  measure  how  long  an  object 
remains  unaltered,  how  long  it  takes  to  optimize,  and  the 
value  of  performing  the  optimizations. 

Wall-clock  Time  v.  Frame  Time 

Because  we  are  interested  in  how  many  times  an  object 
is  modified  versus  how  many  times  it  is  rendered,  it  is 
more  appropriate  to  use  rendering  frame  counts  rather 
than  wall-clock  time.  For  example,  if  we  used  wall- 
clock  time,  and  the  system  pauses  momentarily  (perhaps 
due  to  other  users  on  the  machine)  a  single  frame  could 
take  arbitrarily  long  to  render.  The  ratio  of  how  fre¬ 
quently  the  object  is  modified  to  how  frequently  it  is 
rendered  is  what  is  important. 

While  frame-counting  is  necessary  to  determine  when  to 
optimize,  wall-clock  time  is  necessary  to  compute  the 
effectiveness  of  the  optimizations.  We  measure  the  ren¬ 
dering  times  of  objects  in  both  their  unoptimized  and 
optimized  states. 

Important  Information  for  the  Algorithm 

AUT  —  Average  Unaltered  Time:  the  ratio  of  the  num¬ 
ber  of  frames  where  an  object  is  not  altered  to  the  total 
number  of  frames  (This  is  a  running  total  average,  but 
other  options  are  discussed  later). 

TTRU  --  Time  to  Render  Unoptimized:  the  amount  of 
time  to  render  an  object  without  any  optimizations. 

TTRO  —  Time  To  Render  Optimized:  the  amount  of 
time  to  render  an  object  once  it  has  been  optimized. 

OT  —  Optimization  Time:  the  time  it  takes  to  perform 
the  optimization  on  the  object. 

Computing  Variables 

Since  there  already  is  a  penalty  for  loading  an  object 
from  the  disk  we  expend  slightly  more  time  to  obtain 
timing  information.  We  load  the  object  and  render  it 
several  times  without  performing  a  swapbuffert) 
call.  During  this  time  we  gather  the  TTRU.  the  TTRO 
and  the  OT.  We  also  create  the  streamlined  array  for 
each  node.  The  performance  cost  of  gathering  this  infor¬ 
mation  is  not  observable,  as  it  is  dominated  by  the  time 
to  read  the  object  from  the  disk. 
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Dynamically  Created  Objects 

During  the  execution  of  the  program,  subtrees  may  be 
reparented.  effectively  creating  new  objects,  and  the 
timing  variables  cease  to  be  representative.  In  this  case, 
we  use  a  simple,  coarse  predictive  function  based  on  the 
number  of  polygons  in  a  subtree 

Based  on  timings  taken  on  a  large  number  of'subtrees  on 
an  SGI  Reality  Engine"  [3j.  we  find  for  an  N  polygon 
subtree,  the  representative  times  are: 

EstimatedTTRU  =  (0  0000127  *  N)  seconds 
EstimatedTTRO  =  (0.0000038  *  N)  seconds 
EstimatedOT  =  (0.0000879  *  N)  seconds 
The  Utility  Function 

For  each  node,  we  siore  the  TTRU.  TTRO.  and  OT.  The 
utility  function  computes  the  amount  of  savings  we  will 
obtain  over  the  average  unaltered  time  (AUT)  and  adds 
the  cost  of  performing  the  optimization.  The  total  is 
compared  to  the  cost  of  rendering  unoptimized  over  the 
same  AUT: 

if  (TTRO*  AUT  +  OT  <  TTRU* AUT)  then  optimize... 

This  simple  algorithm  docs  not  prevent  arbitrarily  bad 
hitches.  For  example,  if  the  object  has  not  changed  for  a 
very  long  time,  but  the  optimization  time  (OT)  is  five 
seconds,  the  algorithm  would  perform  the  optimization, 
and  the  system  would  stall  for  five  seconds.  This  prob¬ 
lem  can  be  solved  by  placing  a  hard  upper  limit  on  the 
allowable  OT. 

Invalidating  the  Optimizations 

Since  our  system  supports  a  dynamic  tree,  we  must 
invalidate  the  caches  when  an  object’s  characteristics 
change  (e.g.  color,  translucency.  texture),  when  the 
object’s  matrix  undergoes  a  transformation,  and  when 
reparenting  occurs  The  caches  are  marked  dirty  and  the 
rendering  engine  traverses  the  unoptimized  hierarchy 
instead.  Since  each  node  maintains  its  own  streamlined 
array,  any  unaltered  node  keeps  its  streamlined  array: 


MEASUREMENTS 

The  effectiveness  of  this  optimization  mechanism 
depends  on  how  Irequently  an  application  alters  an 
object.  If  the  object  is  altered  continuously,  then  no  opti¬ 
mizations  are  performed.  If  an  object  is  never  altered, 
then  it  is  optimized  once  and  remains  in  the  optimized 
state  for  the  duration  of  the  application. 


To  establish  that  these  optimizations  produce  a  worth¬ 
while  savings,  we  measured  the  time  to  render  a  variety 
of  objects  when  they  are  optimized  and  when  they  are 
unoptimized.  The  results  are  shown  in  Table  1 .  The 
graphical  objects  in  the  table  represent  several  contrived 
and  actual  objects  to  explore  variations  on  tree  configu¬ 
rations  and  redundancy  removal.  Note  that  these  speed- 
ups  are  greater  than  2.5;  actual  day-to-day  use  achieves 
roughly  a  2.5  speedup  because  of  constant  cost  opera¬ 
tions  per  frame  such  as  clearing  and  swapping  the  frame 
buffer,  which  dilutes  the  speedup  somewhat. 

Note  to  the  reviewers:  the  enclosed  video  tape  shows  the 
amusement  park  simulation  rendering  at  12  frames  per 
second  without  optimizations  and  29  frames  per  second 
with  the  optimizations  engaged. 

As  future  work  we  would  like  to  gather  statistics  about 
how  frequently  objects  are  optimized  and  how  long  they 
remain  optimized. 

CONCLUSION 

The  graphics  database  is  accessed  by  both  the  applica¬ 
tion  program  and  the  rendering  engine,  but  the  usage 
patterns  and  frequency  of  access  dictate  very  different 
internal  representations.  Transforming  a  subtree  into  a 
render-optimized  list  steals  rendering  time  which  may 
be  recouped  over  future  frames.  The  question  of  utility 
becomes,  “Is  it  worth  the  time  to  optimize  now,  to  speed 
up  the  application  for  the  future?”  By  observing  that 
some  parts  of  the  tree  are  active  for  discrete  periods  of 
time,  we  have  implemented  a  runtime  optimization 
mechanism  which  optimizes  only  local  portions  when 
the  utility  of  optimization  appears  worthwhile.  The 
results  are  dependent  on  usage  patterns,  but  initial  tim¬ 
ing  experiments  indicate  that  this  mechanism  is  useful 
for  improving  runtime  efficiency.  Our  initial  measure¬ 
ments  indicate  a  factor  of  2.5  increase  in  rendering 
speeds  when  the  optimization  mechanism  is  employed. 

HIGH  LEVEL  OBSERVATIONS 

We  have  two  high  level  observations  based  on  this 
implementation.  The  first  is  that  preliminary  results  of 
employing  this  mechanism  look  promising.  Alice  was 
recently  used  in  a  graphics  class  project  where  ten  stu¬ 
dents  built  an  amusement  park  (each  student  built  indi¬ 
vidual  rides).  This  was  a  fair  test,  involving  an 
application  written  by  a  ten  person  team,  unaware  of  the 
underlying  optimization  techniques.  The  optimization 
mechanism  improves  the  rendering  by  a  factor  of  2.5. 

Our  second  observation  is  that  trees  are  typically  con¬ 
structed  with  very  little  depth  —  on  the  order  of  five  lev¬ 
els  or  less. 

FUTURE  WORK 

The  following  is  a  brief  list  of  issues  we  intend  to  con¬ 
sider  as  we  continue  this  work. 
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Spatial  Coherency 

The  rendering  engine,  by  computing  the  bounding  vol¬ 
umes  of  subtrees,  knows  which  objects  in  the  tree  are 
located  near  each  other  after  the  matrix  transformations. 
This  may  not  be  identical  to  the  way  the  user  has  con¬ 
structed  the  parent-child  relationships  of  the  tree. 

For  portions  of  the  database  which  do  not  change  over 
long  periods  of  time,  the  rendering  engine  could  flatten 
the  application  tree  and  then  reconstruct  a  different  tree 
based  on  spatial  locality.  This  would  allow  for  more  effi¬ 
cient  high-level  culling 

Timing  Across  Runs 

We  currently  compute  all  variables  for  the  optimizations 
at  runtime.  There  may  be  some  benefit  in  storing  the 
timing  data  across  runs  This  information  might  be  use¬ 
ful  when  determining  the  utility  of  flattening  and  may 
serve  as  a  second-order  statistic  about  the  nature  of  the 
object  (e.g.  the  “lamp"  object  is  used  by  many  applica¬ 
tions  as  static  decoiution) 

Averaging  Differently 

We  currently  compute  the  Average  Unaltered  Time 
(AUT)  over  the  enlire  run.  An  alternate  approach  is  to 
weight  the  timings,  so  that  over  time  the  more  recent 
alterations  influence  the  average  more  than  alterations 
having  occurred  a  long  time  ago.  The  general  problem  is 
similar  to  the  page  replacement  problem  in  operating 
systems. 

Application  Hints  and/or  Explicit  Control 

It  might  be  prudent  in  some  cases  to  allow  the  applica¬ 
tion  to  explicitly  express  good  moments  to  perform  opti¬ 
mizations.  For  example,  if  the  application  knows  that 
the  user  has  paused  or  gone  into  another  mode,  then  that 
might  be  a  good  time  to  optimize. 

Progressive  Flattening 

For  example,  if  we  flatten  a  bunny  object  which  has 
children  nodes  of  head,  body  and  arms,  and  then  we 
rotate  the  head,  the  entire  head  tree  will  be  unflattened. 
If.  instead,  we  progressively  flatten  each  subtree  into 
larger  and  larger  lists,  w'c  can  unflatten  only  the  portions 
which  have  been  altered,  rather  than  the  whole  subtree. 

Combine  with  Other  Optimization  Techniques 

Using  this  optimization  mechanism  does  not  preclude 
off-line  optimization  For  example,  with  a  static  data¬ 
base  such  as  the  Bei  keley  Walkthrough,  off-line  optimi¬ 
zation  can  provide  a  great  deal  of  effective  visibility 
culling.  During  runtime  a  given  “cell  of  visibility”  may 
still  have  a  large  number  of  objects.  Our  mechanism 
may  then  be  effective  for  improving  the  cell. 
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Table  1:  Optimization  Timing  Measurements 


pie-optimized  tree 
characteristics 

pre-optimized 

optimized 

M.ix 

poly¬ 

gons 

time  to 
optimize 

ob|eci 

1 1  cc 

1  )epth 

nodes 

Set 

Color 

Set 

Normal 

time 

Set 

Color 

Set 

Normal 

time 
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bunny 

■a 
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389 
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0.00500 

36 

389 

0.00144 

0.02964 

3.47 

cow 

mil 

3263 

12330 

0.04557 

i 

12255 

0.01626 

0  41885 

2.80 

old  demo  loom 

■ 

609 

2462 

0.00744 

82 
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0.04448 

3.50 

loom 

T 

12 

196 

_ 
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0  00240 

38 

254 

0.00080 

001691 

3.00 

new  demo  room 

V. 

55 

220 

0.00067 

7 

55 

0.00016 

0  00417 

4.19 

10  levels  deep 

m 

10 

20 

20 

80 

0.00027 

1 

20 

0.00008 

0.00187 

3.38 

m 

EO 

40 

40 

160 

0.00064 

1 

40 

0.00013 

0  00371 

4.92 

30  levels  deep 

30 

■a 

60 

60 

240 

0.00093 

1 

60 

0.00019 

0  00536 

4.89 

10  levels  wide 

1 

20 

20 

80 

0.00027 

1 

20 

0.00008 

0.00183 

3.38 

20  levels  wide 

1 

20 

40 

40 
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0.00054 

Gl 

40 
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0.00361 

4.50 

30  levels  wide 

1 

30 

60 

60 
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0  00085 

■D 

60 
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0.00545 
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m 
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m 
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0.00198 

0  04649 
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m 
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003285 

i 

2048 

0.00834 
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3.94 

12  full  binary 

g 2 

4096 
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0.16171 

i 
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0.04178 

0  84584 

3.87 

200  node  eoloi 

i 

200 

200 

200 

800 

0.00370 

200 

1 

0.00096 

0.02164 

3.85 

m 

300 

300 

1200 

0.00563 

300 

1 

0.00133 

0.03298 

4.23 

i 

iHH 

200 

200 

800 

0.00385 

1 

200 

0.00082 

0.02219 

4.70 

300  node  normal 

i 

3(K) 

300 

300 

1200 

0.00596 

1 

300 

0.00120 

0.03381 

4.97 

Still  1C 

amusement  paik 

■ 

3H5 

3490 

3490 

14596 

0.06366 

1842 

2269 

0.01696 

0.00728 

3.75 

animated 
amusement  park 

32 

385 

3490 

3490 

14596 

0.06366 

vari¬ 

able 

vari¬ 

able 

0.02232 

040113 

2.85 

“opt.  time”  is  the  Optimization  Time.  OT 

“ratio"  is  the  Time  To  Render  Unoptimized  (TTRU)  /  Time  To  Render  Optimized(TTRO) 

“#  levels  deep”  is  a  1  node  wide.  #  levels  deep  tree 
“#  levels  wide”  is  a  I  node  deep.  #  levels  wide  tree 
“#  full  binary"  is  a  #  lex  el  deep,  full  binary  tree 

“#  node  color"  is  a  I  level  deep.  #  level  wide  tree,  with  every  polygon  set  to  a  different  color 

“#  node  normal"  is  a  I  level  deep.  #  level  wide  tree,  with  every  polygon  rotated  to  produce  a  different  normal 
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